公司新来了个90后，把旧的DRP“吊打”和“按到地上摩擦”
常言道：流水不腐、户枢不蠹。您企业的灾难恢复计划是否 N 久没被更新了？我们来看看一位 90 后是如何对 DRP 进行整改的案例。
话说我们公司应急响应中心新来了一位小嵇同学。作为典型的90后，他受过良好教育、个性张扬、特立独行。
那天，他对我们说：他觉得咱们现在的 DRP（灾难恢复计划）就像他过去弹钢琴一样，存在着如下三大问题：
我们当初听过了后，也没在意。可没想到几日后，他在某次 IT 管理层会议上，一边问着：“惊喜不惊喜？意外不意外？”，一边向我们展示了他改进后的 DRP。
大家虽然不喜欢这种粗暴的“手撕”方式，但耐着性子认真阅读之后，也不得不承认他的更改的确解锁了一些新技能，并填补了一些老坑点。
总的来说，这份新的 DRP 基本上“没毛病”。下面就让我们来具体看看他在原来的基础上做了哪些改进。
事前篇
清晰定义“灾难”
“傻傻”分不清楚，但是你要分清楚
原来的 DRP 上手就谈如何应对灾难，可是公司上上下下在多数情况下，经常会混淆问题（Problem）、紧急情况（Emergency）与灾难（Disaster）之间的细微差别，并造成了一旦出事就“匆忙上阵”，出现人浮于事的状况。
因此，他开宗明义地做了如下定义：
问题：是指单个或少量的计划外的业务和/或服务中断或质量水平骤降，造成损失较轻，直接责任部门容易迅速实施补救。
不涉及到 DRP 和 DR 相关团队，一般小于 24 小时。
紧急情况：是指多个不可预见性的业务和/或服务中断情况的组合，造成了一定的损失或破坏，多个部门需要尽快解决。
DR 相关团队需时刻根据实际情况触发 DRP，一般大于 24 小时但小于 48 小时。
灾难：是指成规模的对资产和/或服务造成了损害、损失或破坏的重大事件。需要公司管理层的参与。
DR 相关团队立即启用 DRP 并分步骤实施 DR，一般大于 48 小时。
厘清上述关系，可见对于掌握 DRP 的触发条件是至关重要的，而后续的恢复活动才能够有的放矢地进行开展。
BIA + RA
“预则立，不预则废”
业务系统在日常运营过程中，可能发生的各种灾难，对我们来说就是“天灾人祸”类的重大事件。
过去的 DRP 对于当前的生产系统来说不但已经陈旧，而且有着较大的出入。
因此要想达到有条不紊的恢复效果，就需要通过 BIA（业务影响分析）和 RA（风险分析）来识别出那些与本公司日常运营密切相关的职能模块和关键应用。
小嵇通过参考各种 SLA（服务水平协议）、事故记录、以及内/外审报告，对各类主/次要系统定义了 MTD（最大允许中断时间），区分了轻重缓急，并排定了恢复的先后次序。
在 BIA 中，他依次以“业务职能”和“关键应用”两大部分为出发点，分别根据关键（1-4 小时）、紧急（24 小时）、重要（72 小时）、一般（7 天）、非必要（30 天）五种 MTD，拟出了 2×5 =10 张表格。
下面就是两类表头的示例，大家可以批判地审视一下：
上述的 BIA 主要从“知己”的角度出发，为了实现“百战不殆”的小目标，它还努力定义了“知彼”，即 RA。
下面就是他依次引入的三个维度的参考指标：
内/外部威胁源或威胁代理：自然层面上的各种灾害；技术层面的，如软/硬件损坏所造成的大量数据丢失和分布式拒绝服务攻击等。
支撑系统方面的，如供电、空调和接入网络等；以及人为方面，如故意使用恶意软件进行破坏和操作疏忽与失误等。
风险可能性：基于过往事件/事故的记录、放置和使用区域特征、相关合规要求、自身鲁棒性，得出高中低的性质。
影响范围：整个组织/所有外部客户、多个站点/多个系统与服务、或是单个站点/单个系统。
最后将这些都对应到各个业务模块上形成风险分析的矩阵。由此可见，他通过对现有系统的全方位、立体“扫描”和剖析，扫清了识别层面上的“死角”，为必要时的全面复盘做好了基础性的准备工作。
团队与责任
拒绝懵逼、也拒绝“布朗运动”
旧的 DRP 仅简单定义了一个应急响应小组来全面履行灾难恢复，可是有过实战经验的小伙伴一定知道，这种“低配”是完全不够的。
在此，小嵇同学细化并深耕了 DR 团队，并为他们“赋能”。下面让我们来看看这些“破壁”的人们需要哪些必备的技能，才能帮助我们把灾难怼回去：
恢复管理团队：
设置紧急热线电话、保持“呼叫树（Call Tree）”的准确性。
审查通知模板、灾难评估报告、测试结果。
确保相关人员的技能和意识培训、以及演练的落实。
定期审阅 DRP 并落实更新。
批准和控制恢复全程的成本。
检查确认系统的恢复。
损失评估团队：
评估灾难影响程度、量化损失以获赔偿。
起草并提交损失报告。
设施资源团队：
编录并更新生产环境中的软/硬件列表和备件库存情况。
保证能在必要时获取外部服务与支援。
维护离站资源和备用站点，提供各类相关的参考文档和操作手册。
必要时安排离站资源向受损主站的调配，以及人员转往备用站点的各种后勤。
技术恢复团队：
向评估团队提供必要的技术和数据信息。
提出过渡性的临时运营方案。
按照既定的顺序执行具体灾难恢复的各项技术操作。
防止次生灾难的发生。
灾难期间，对备用站点提供各项技术支持。
事后总结，提出加固方案，并更新 DRP。
公关法务团队：
在各个阶段，保持与各个方面的沟通，并使用既定的模板进行相关发布。
给予法律、合规方面的指导。
如有必要，则实施电子或物理取证。
由上可见，在“大难临头”之时，如果没有明确规定好计划中相对应的团队角色和其负有的职责的话，别说什么组队打“怪”了，只要出现一位“猪一样的队友”，大家就真的只能去“领盒饭”了。
事中篇
设定应对流程
“审判日”的绝地反击
曾经的 DRP 在这个环节写得“头重脚轻”，开始响应阶段细致入微，甚至有些吹毛求疵，而实际操作中并无过多的时间去层层报告和批示。
另外，在原 DRP 中，其恢复过程过于“速度与激情”化，导致业务回归上线后就草草收场，缺乏必要的确认与总结，而小嵇改版后的 DRP 则能明显体现“步步为营”的流程感。
让我们一起往下看：
事故出现，初步检测与识别，并定性灾难。
通知管理层，吹响 DR 团队的“集结号”。
DR 团队迅速拍马赶到，各司其职，展开深入调查与取证。
损失评估，分析灾难源、填写如下灾难评估模板。（注意：评估报告需在灾难发生的 4 小时之内完成并提交。）
对内/对外宣告灾难。注意对内可以使用不同颜色的通知模板，以便受众一目了然。对外提供可能问及的技术细节解答和支持。
在受灾处，根据主次关系和既定顺序，先抑制再恢复，逐步实施各种基础设施、通信线路、硬件、软件的安装和配置、以及数据的恢复。
在 DR 的各项活动中，除了要注意各个 RTO 与“里程碑”外，也要注意填写并提交如下的日志检查表。
实时评估并验证恢复的有效性。如有必要，迅速修改恢复流程与方法，避免滋生次生破坏。
各个受影响的部门对灾难的恢复结果予以确认，并对内/外宣布完成。
总结评审执行效果，分析与原计划的偏离，并提出改进措施。
事后篇
更新与测试
自建生态，形成闭环
我们或许都有这样的共识：IT 服务和系统是随着企业的业务动态生长，并不断迭代的，可见旧版本的 DRP 之所以能被小嵇“吊打”和“按到地上摩擦”，就是因为它针对的是彼时多年前的系统状态。
因此，为了防止老化和淘汰，小嵇版本的 DRP 特地在最后部分增加了按需更新和例行测试。
具体来说，他罗列到的更新触发条件包括如下因素的增加、变更与淘汰：
服务器/用户端硬件设备与模块
网络设备、连接与架构环境
机房、数据中心与外部链路
关键软件程序、应用平台和服务系统
办公自动化（OA）与协同（Collaboration）相关软/硬件产品
关键配置与数据格式
服务策略（SLA）与员工规则
为了避免出现“扎心了，老铁，这方案没法实施”的情况发生，小嵇也定义了相应的例行维护与测试频率：
俗话说：猫有九条命，但是我们的业务服务系统可没有那么多的命哦。
因此，唯有保持 DRP 可操作性和可实现性，才能让这个所谓的刚性需求不断地“满血复活”。
小结
前些时“第一批 90 后已经…”的各种段子刷爆了微信朋友圈。
但是不可否认的是 90 后一代正在成为企业内的中坚技术力量，并正在逐步向管理岗位迈进。
虽然我们公司里的 90 后在技术水平上经常被黑，但是讲真：这次以小嵇为代表的 90 后对于 DRP 的大刀阔斧式的改进，让我们这些自称佛系，却时常油腻的 70 后老年人不得不刮目相看了。
作者：陈峻
编辑：陶家龙、孙淑娟
投稿：有投稿、寻求报道意向技术人请联络 editor@51cto.com
陈峻（Julian Chen） ，有着十多年的 IT 项目、企业运维和风险管控的从业经验，日常工作深入系统安全各个环节。作为 CISSP 证书持有者，他在各专业杂志上发表了《IT运维的“六脉神剑”》、《律师事务所IT服务管理》 和《股票交易网络系统中的安全设计》等论文。他还持续分享并更新《廉环话》系列博文和各种外文技术翻译，曾被(ISC)2 评为第九届亚太区信息安全领袖成就表彰计划的“信息安全践行者”和 Future-S 中国 IT 治理和管理的 2015 年度践行人物。
精彩文章推荐：